home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
dns
/
dns-minutes-93mar.txt
< prev
next >
Wrap
Text File
|
1993-04-28
|
13KB
|
292 lines
CURRENT_MEETING_REPORT_
Reported by Rob Austein/Epilogue Technology
Minutes of the Domain Name System Working Group (DNS)
The meeting opened with a few comments by the Chair regarding the future
of the Working Group. In brief, the Working Group has been in existence
for a long time, with ill-defined goals and an odd mixture of tasks.
Some of the Working Group's tasks are of an ongoing nature, some are
very specific with definite goals and milestones. As currently
organized, the Working Group does not fit well into the IETF
administrative structure. At some point in the relatively near future
it may be necessary to restructure the Group to address this problem.
The Chair will be working with the Director of the new IETF Service
Applications Area to address this issue.
Given the state of flux that the IESG and the IETF itself were in at the
time of the Working Group meeting, the Working Group decided to spin off
a few well-defined tasks to ``sub-groups'' but otherwise leave the
current DNS Working Group structure unchanged. Whether the
``sub-groups'' would be full-fledged IETF working groups or just
subcommittees of the DNS Working Group was left unspecified; the
organizers of the three sub-groups spun off at this meeting all
subsequently expressed a distinct preference for being subcommittees
rather than independent working groups.
The next item of business was to dispose of some old tasks that were
still listed on the Group's Charter. The following tasks were removed
from the task list:
1. Discussion of adding a Responsible Person RR.
2. Discussion of adding network naming capability to the DNS.
3. Implementation catalogue for DNS software.
4. Writing a ``DNS operators guide''.
Tasks (1) and (2) were done years ago and published in RFCs 1183 and
1101, respectively. Task (3) was killed for lack of any volunteers who
care about it enough to write it; if such a volunteer exists, that
person should just write the document, we don't need a group effort to
do this.
The Group also briefly discussed writing a ``DNS Operators guide'', Task
(4). Since both RFCs 1032-1033 and an O'Reilly Associates book exist on
the subject, the Group felt that writing such a document would be a
waste of time. Stuart Vance agreed to write a one-page document
referring readers to the O'Reilly Associates book; if there are other
published documents on this subject, whether commercial or free, please
announce them on the Namedroppers list for possible mention in Stuart's
reference.
1
Next on the Agenda were the three tasks that were felt by the Group to
be of sufficient interest to form a subgroup to work on each task. Each
task was discussed for long enough to air some of the issues that needed
to be addressed, then the Chair called for someone willing to organize a
subgroup willing to attack the problem and report back.
1. Scaling problems of ``big zones'', particularly the .COM zone.
The Working Group has been kicking this problem around for a year
without much progress. Discussion was limited to a summary of the
problem by Mike St. Johns and to new suggestions by the Working
Group. One-line summary: some of the first-level DNS zones are
approaching the size of the old NIC HOSTS.TXT file, which leads to
various technical and political problems. Please see the Minutes
of previous DNS Working Group meetings for background on this
discussion.
John Romkey pointed out that, as the Internet grows and more hosts
are registered in the DNS, it will be increasingly hard to maintain
any kind of obvious correlation between DNS names and ``real''
names. All the proposed ``solutions'' to the .COM zone problem
will exacerbate this situation; the only exception is the
``XYZCORP.X.COM'' partitioning scheme, which, while ugly, is at
least obvious. In the long run we need a solution to the problem
of unintuitive names in the DNS. Whatever solution we pick for the
.COM zone should be chosen with this in mind, so that we don't make
the problem worse.
Bill Manning agreed to lead a subgroup to investigate the problem
and report back. The subgroup's mailing list is ``bigz@rice.edu'',
send mail to ``bigz-request@rice.edu'' to join the list.
2. DNS security.
The Working Group heard a report from Steve Crocker, Director of
the IETF Security Area. There are really two tasks under
discussion.
(a) The first security task is bulletproofing the DNS so that it
cannot be spoofed without ability to spoof IP addresses; this
is, essentially, Paul Mockapetris's ``Just As Good As IP''
security mechanism, as described by Paul at the ``DNS-II'' BOF
held at the 25th IETF in Washington DC. This level of security
could also be described as ``robustness,'' that is,
implementation of Paul's techniques would help defend the
global DNS database against some of the accidental spoofing
that has happened over the years. This is primarily an
implementation issue, and wheels are already rolling to get
this mechanism into a near-future release of BIND. Watch the
namedroppers list for announcements.
(b) The second security task is specifying a mechanism by which RRs
could be accompanied by digital signature information for
authentication. Both for backwards compatibility with existing
DNS software and in order to avoid running afoul of U.S. export
2
controls on cryptographic software, this signature must be an
optional mechanism, added in such a way that non-players can
ignore it and still comply with the DNS protocols. The general
idea is to define a new RR type, the RDATA portion of which
would be used to contain the digital signature. James Galvin
agreed to lead a subgroup to work on this project and report
back to the Working Group. The subgroup's mailing list is
``dns-security@tis.com'', send mail to
``dns-security-request@tis.com'' to join the list.
3. Load balancing.
This task has been with the Working Group for a long time. At the
time of this meeting there were at least four mechanisms proposed
to solve some aspect of the ``load balancing'' problem, some
already in widespread use, one requiring no protocol changes at
all. Tom Brisco and Stuart Vance agreed to lead a subgroup to
investigate this problem and document their conclusions. The
subgroup's mailing list is ``dns-wg-lb@ns1.rutgers.edu'', send mail
to ``dns-wg-lb-request@ns1.rutgers.edu'' to join the list.
Next, the Working Group heard a report on the current status of the DNS
MIB from Frank Kastenholz, representing the IETF Network Management
Directorate. In brief, the DNS MIB has been stalled since the 25th IETF
for two reasons:
1. The Network Management Area Directorate has been busy with the
emerging SNMPv2 specification and suffered some disorganization due
to the abrupt resignation of its Area Director, and
2. The DNS MIB presents some non-trivial problems, because there are
some cases where the ``SNMP way'' and the ``DNS way'' of doing
things are diametrically opposed.
Problem (1) is already being repaired: a new Area Director for Network
Management was elected two days after the DNS Working Group meeting, and
the SNMPv2 specification is on its way out the door.
Problem (2) will be addressed by Frank (representing the Network
Management Area Directorate) and the authors of the DNS MIB.
Frank suggested that the DNS Working Group consider whether or not SNMP
was really the right tool for all of the management tasks addressed by
the DNS MIB, and for the proposed dynamic update mechanism (dynamic
creation and deletion of RRs via a network protocol); it's possible that
extensions to the DNS protocol might be more appropriate for some of
these tasks. James Galvin pointed out a counter-argument: if DNS
management is not done via SNMP, the extended DNS protocol would need to
duplicate much of the mechanism of SNMP, including the security
features. The Working Group decided to press ahead with cleaning up the
3
DNS MIB, given that we've already spent so much time on it.
Next, Susan Thomson gave a presentation on DNS support for PIP. The
presentation was basicly the same material covered in the PIP-DNS
Internet-Draft (``draft-ietf-pip-dns-00.txt''). The Group discussed
three problems with the PIP-DNS proposal:
1. The PIP-DNS proposal creates two new semi-wildcard QTYPEs (the PIP
document calls these ``special-purpose query types'').
Semi-wildcard QTYPEs have known problems when combined with DNS
caching algorithms, as documented in RFC-973, page 4, ``MD and MF
replaced by MX''. The Working Group recommended that the PIP Group
redesign their proposal to get rid of the semi-wildcard QTYPEs.
2. The proposed BBD (BackBone Descriptor) RR format defined a
one-octet field to select the character set used in the variable
length text portions of the RR. The Working Group recommended that
this be eliminated and that the variable length text portions of
the RR be limited to the NETASCII character set.
3. PIP includes a mechanism by which a PIP implementation can know
that it needs to get a fresh copy of an RR. The PIP implementors
would like to have a way to speed propagation of fresh information
when this happens. Discussion of this subject on the Namedroppers
list suggests that one way to accomplish this would be the addition
of an RR timestamping mechanism to the DNS. To date we do not know
how to add such timestamps without an incompatible change to the
DNS protocols, so we may not be able to help the PIP implementors
here. This issue was left open, due to time pressure at the
Working Group meeting.
There was a brief discussion of the proposed X.400 ``temporary'' routing
mechanism (using the DNS to replace X.400 routing tables). Those
members of the Working Group who had read the proposal felt that it was
seriously flawed and could not be implemented as specified. Rob Austein
and Jon Postel volunteered to meet with the authors of the proposal in
order to find the right answer to this problem. Said meeting took place
two days later, and resulted in a better solution, to be documented by
Claudio Allocchio, one of the authors of the original proposal.
At this point, having run out of time and having covered all the major
items on the Agenda, the meeting was adjourned.
Attendees
N. Akiko Aizawa akiko@nacsis.ac.jp
Philip Almquist almquist@jessica.stanford.edu
Randall Atkinson atkinson@itd.nrl.navy.mil
Robert Austein sra@epilogue.com
David Battle battle@cs.utk.edu
David Bolen db3l@ans.net
4
Erik-Jan Bos erik-jan.bos@surfnet.nl
David Bridgham dab@epilogue.com
Thomas Brisco brisco@pilot.njin.net
Sandy Bryant slb@virginia.edu
Henry Clark henryc@oar.net
Wayne Clark wclark@cisco.com
David Conklin conklin@jvnc.net
Stephen Crocker crocker@tis.com
John Curran jcurran@nic.near.net
Chas DiFatta chas@cmu.edu
James Galvin galvin@tis.com
Richard Graveman rfg@ctt.bellcore.com
Steven Hubert hubert@cac.washington.edu
Daniel Karrenberg daniel@ripe.net
Frank Kastenholz kasten@ftp.com
David Katinsky dmk@pilot.njin.net
Kenneth Key key@cs.utk.edu
John Klensin klensin@infoods.unu.edu
John Linn linn@gza.com
Daniel Long long@nic.near.net
Steven Lunt lunt@bellcore.com
Paul Lustgraaf grpjl@iastate.edu
Bruce Mackey brucem@cinops.xerox.com
Bill Manning bmanning@sesqui.net
Clifford Neuman bcn@isi.edu
William Nowicki nowicki@legato.com
Masataka Ohta mohta@cc.titech.ac.jp
Andrew Partan asp@uunet.uu.net
Brad Passwaters bjp@sura.net
Michael Patton map@bbn.com
John Penners jpenners@advtech.uswest.com
Jon Postel postel@isi.edu
Robert Reschly reschly@brl.mil
John Romkey romkey@asylum.sf.ca.us
Jon Saperia saperia@lkg.dec.com
Carl Schoeneberger 70410.3563@Compuserve.com
Tim Seaver tas@concert.net
Allyson Showalter allyson@nsipo.arc.nasa.gov
Michael St. Johns stjohns@darpa.mil
Martha Steenstrup msteenst@bbn.com
Bernhard Stockman boss@ebone.net
Susan Thomson set@bellcore.com
L. Stuart Vance vance@tgv.com
Ruediger Volk rv@informatik.uni-dortmund.de
Chuck Warlick warlick@theophilis.nsfc.nasa.gov
Jane Wojcik jwojcik@bbn.com
5